This is probably not the right direction. The purpose of serialising is producing something that perform_sql ( https://github.com/TurboGears/tgext.debugbar/blob/master/tgext/debugbar/controller.py#L50 ) can load back and re-run the query with. So providing a custom serialiser that the user can configure goes in the exact opposite direction of providing a known consistent format that the SQLADebugSection and the perform_sql can share to communicate.

That was the reason why a known ExtendedJSONEncoder was provided to do the job.

Probably extending ExtendedJSONEncoder to format decimals as numbers that the json loader can read back is enough to solve the crash and allow the perform_sql to re-run the query

I'm not proposing using a custom serializer for the debugbar, I'm proposing that, when you already are using a custom json serializer with sqlalchemy, the sqlalchemy tab of the debugbar should use that same serializer on the sqlalchemy tab of debugbar instead of (as it happens in our case) just showing "Unable to serialize the query parameters". Why would you want the debugbar to use a different serializer than the app? PS: the decimals situation would not prevent the crash for us because our serializer supports more types other than decimals.

The reason for the debugbar to use a serializer that is not the same as the app is because the debugbar must be able to deserialize for perform_sql to work.
In theory as the outgoing and receiving application is the same during the same runtime, we could get rid of the JSON serializer and use pickle (as it's a trusted debug environment). That would allow the debugbar to serialize any value and deserialize it and we could just repr for the visualization part (which concerns me far less).